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METHOD ANB APPARATUS FOR 
STREAMING DATA 

5 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application claims priority from provisional patent application 
10 60/153,905, entitledMETHOD AND SYSTEM FOR VIDEO DELIVERY OVER 
DATA NETWORKS, filed September 14, 1999. 

The above referenced application is incorporated herein by reference for all 
purposes. The prior application, in some parts, may indicate earlier efforts at 
describing the invention or describing specific embodiments and examples. The 
15 present invention is, therefore, best understood as described herein. 

FIELD OF THEINVENTIQN 

The invention generally relates to methods and/or devices related to data 
transmission. More particularly, the invention in various aspects, relates to 
20 multimedia data methods and implications and to a system and/or devices and/or 
methods for improved caching that is particularly applicable to streaming data. 

Copyrig h t Notice 

A portion of the disclosure of this patent document may contain materials 
25 that are subj ect to copyright protection. The copyright owner has no obj ection to the 
facsimile reproduction by anyone of the patent document or tiie patent disclosure, 
as it appears in the Patent and Trademark Office patent files or records, but 
otherwise reserves all copyright rights whatsoever. 

30 
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PrinrPuhlications 

The following publications may be related to the invention or provide 
background infoimation. Listing of these references here should not be taken to 
indicate that any formal seardi has been completed or that any of these referraices 
5 constitute prior art. 

Tt ArgOROTIND OF TtTK TNVENTION 

Thelntemetis arapidly growing conomunicationnetwoik of interconnected 
coiiq)uteis around the world. Together, these millions of connected con5>uters form 
10 a vast repository of hypermedia information that is readily accessible by users 
through any of the connected computers fix>m anywhere and anytime. As there is 
an mcreasing number of users who are connected to the IntCTnet and surf for various 
information, they meanwhile create tramendous demands for more content to be 
available and methods to deliver them on the Internet. Currentiy, the most 
15 commonly availableinformationthatisdeliverableonthelntemetmayincludetext 
information, images and graphics, videos and audio clips. 

Continuous information such as continuous videos, audio clips, audiovisual 
or other multimedia works (referred to below collectively as "media") may be one 
of the frequently requested networic resources. It is therefore not uncommon to 
20 expCTiencethorisandsofaccess requests simultaneouslyto apiece of popular video, 
audio or audiovisual program. Given a network bandwidtti of a data network, on- 
time delivery of the program with tiie guaranteed quality of service (C^S) over the 
network becomes critical. It is evid«atiy impractical to rely on a centiral media 
server to sarvice all of the access requests at the same time. There is flierefore a 
25 need for a veasatile media delivery system that is capable of responding to 
thousands of access requests at the same time meanwhile keeping minimum impact 
on the quality of service. 

Due to the technology improvement in tiie video conq>ression, networking 
infrastructure, and the overall computer c^ability, the realization of Video on 
30 Demand (VOD) service is becoming feasible. During the recent years, tiie 
popularity oflntemet World Wide Web accelerates the deploymentofVOD service. 
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RealNetwork's Real Media and Microsoft's NetShow Service have successfully 
delivered low quality audio/video over the Intemet. Their services have been 
adopted many aspects of multimedia applications including (but not limited to) 
news on demand, distance learning, corporate training, and music distribution. More 
5 people than ever are connecting to the Intemet and surfing the Web ^tes to locate 
the desired infonnation. This triggers more content that is published on the Web. 

To attract people to visit their Web sites, companies design Web pages with 
rich media presmtation, especially by adding continuous media features. However, 
the unique feature of continuous media such as the large storage requirement, high 

10 network bandwidth requirement, and time-critical delivery has made the media 
distribution service over the Intemet a nontrivial problem. This is especially true 
for media works that have high video content. The Video on Demand server is a 
good fit to this problem but not without challenge ahead. A popular web site 
potentially may experience thousands of accesses simultaneously. How a video 

IS servCT system is to process all these requests and deliver the video content to end 
user with the guaranteed quality becomes a pressing issue. One approach 
addressing the server scalability issue is to build aparallel video server by using the 
modem clustering technology. Howev^, this £q>proach caimot easily scale up to the 
magnitude of Web access so that it may be inq)OSsible for a central video server to 

20 service all end-to-end streaming requests. 

Another approach is to add on video delivery service on the existing Intemet 
Web access model. The popularity of Web service has created many new 
businesses. The hitemet Service Providers (ISP) is one of them. They provide the 
necessary infrastmcture, equipment, and service that allow tihieir subscribers easy 

25 and fast access to the Intemet world. To better serve their customers, an ISP office 
provides service to customers within a geographic area. All ISP offices are 
connected via high capacity and expensive backbone networks. All ISP offices 
work together as a xmit. A subscriber's local ISP site is resporsible for receiving the 
user access request, routing the request to the original Web site if necessary, acting 

30 as an agent by receiving the reply from the site, and forwarding the requested 
information back to the requestor. The steps of routing request to the original Web 
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site and receiving the reply from it generate backbone traffic. When more requests 
travel through the backbonenetworks, higher backbonebandwidth is required. This 
means the higher operating cost for the ISP, 

To address this problem, the Ihtemet community has developed a Web 

5 caching strategy. A web proxy server is installed on a ISP site and serves as a 
caching engine to store the ftequently accessed Web page relating to its subscriber 
area. Next time when the cached page is referenced, the proxy server dehvers the 
page from its local cache directly instead of from the original Web server. This 
^proach reduces the client's browsing response time (since the content is from 

10 local proxy server) and also reduces the backbone demands for content delivery, 
thus reducing operating cost. 

The above web-caching model can also apply to large-scale erid-to-end 

video delivery service. 

Many Web proxy server products have been developed, with caching 
15 componentsprincipaUydirectedtotheHTMLpageanditsembeddedimages. Most 
prior web proxies generally are not directed to video proxies. Other earlier 
research addresses QoS (Quality of Service) issues regarding end-to-end video 
delivery, but again not directed to video proxies. Some techniques have proposed 
a video staggering scheme to reduce the backbone bandwidth requiremmt on a 
20 distributed multimedia delivery. In these systems, when a particular video chp is 
requested by the user, a portion of the video content is streamed from cratral video 
server via WAN comection and aportion of the video content is streamed from the 
local proxy server. Both data streams enter a user's playback station. If a large 
portion of data is streamed fix>m the local server, then less data is streaming from 
25 thebackbonechamiel, wMchresultsinlessbackbonebandwidthrequirement Thus, 
a previous video staging technique is to prefetch a predetermined amount of video 
data and store them a priori at a proxy server. The proxy server stores Ifae 
predetermined video content based on the access pattern generated in previous 
profile cycle, not current access behavior. Some earlier schemes can improve 
30 backbone utilization only for content encoded as VBR (variable bit rate) format. For 



wo 01/020910 PCT/USOO/25059 



5 

CBR (constant bit rate) encoded video content, some prior ^proaches do not reduce 
any WAN bandwidth requirement 

Another approach caches a sliding window worth of data for each video 
being displayed so that a video can be partially stored at the proxy server. Thus, if 
5 a movie request by a client arrives at a proxy server, the proxy server would store 
a sliding window of W minutes of the movie in its local cache while the movie is 
beiQg streamed and delivered to the client. If a new request arrives witibin the time 
window, the data in the local cache may be utilized so as to reduce the amount of 
data that has to be sent from the central server and thereby reducing the backbone 

1 0 bandwidth requirement. In one such sliding window approach described by Chan 
et al. in "Caching Schemes for Distributed Video Services," 1999 IEEE 
International Conference on Communications (Vancouver Canada)^ June 1 999, the 
window size is extended upon receipt of a new request for the same movie from that 
point on to a frirther of W minutes. While the sUding window scheme may reduce 

IS the backbone bandwidth requirement, suchreductionis generally unpredictable and 
depends upon whether frirtherrequests for the same movie arrive within the window 
or not and how frequently such window is extended as described by Chan in the 
above-referenced article. Thus, if the further requests arrive outside of the sliding 
window, there will be no reduction in the backbone bandwidth. 

20 Thus, none of the above approach^ is entirely satisfactory. It is, therefore, 

desirable to provide an improved caching scheme whereby tiie above described 
difficulties are alleviated. 

SUMMARY OF THE INVENTION 

25 This invention is based on the observation that, by storing or caching data 

from a requested media title where the cached data is distributed over the title, the 
above-described dif&culties can be overcome. When the title that is partially 
cached by the proxy server is requested by client, only the portion of the title that 
is not cached by the proxy will need to be obtained from the central server over the 

30 backbone. Since the data from the title that is cached by the proxy is distributed 
over the title, one can achieve reduction of the peak backbone bandwidth fix>m the 
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central server required for transmitting the portion of the title. This is vray different 
from the sliding window approach where the data stored is concentrated in the 
window, and no data outside the window is cached. The instructions for the method 
described above and below may be downloaded fi^om a data source or from a 
5 computer readable medium. For example, by downloading instructions for the 
method from a data source, such as directly or through the internet or any otiier type 
of conaputer network, or from an optical or magnetic storage medium, the 
instructions or program so obtained would enable a client device to carry out the 
methods described above and below. Thus, the computer readable medium storing 

1 0 such instructions and the process of sending such instructions (or causiug them to 
be sent) through a computer link are within the scope of the invention. 

In the preferred embodiment, the media title is divided into blocks and each 
block is furtiier divided into sub-blocks, where the blocks are transmitted 
sequentially to the cUent. In such embodiment, the proxy server caches sub-blocks 

1 5 that are distributed over the blocks. In this manner, the peak transmission bit rate 
of the central server for transmitting the title is rediiced. A nmnber of different 
embodiments are possible. Thus, the sub-blocks cached can be distributed 
randomly over the title, such as where the sub-blocks are selected fix>m the sequence 
of blocks by the use of a random number generator. In another embodiment, the 

20 same number of sub-blocks from each block of the title are cached by the proxy 
SCTver. Or, one can store a sub-block about every nblocks along the time sequence 
of the blocks, n being a positive integer. In all such embodiments, one can insure 
reduction of the peak transmission bit rate of the central server. Different from the 
sliding window scheme described above, the cached sub-blocks are also prefaably 

25 stored for time periods that are independent of passage of time. 

According to another aspect of the invention, progressive media caching 
may be employed for delivering media selections to one or more media clients over 
a data network. The data network may be the Internet, the Intranet or a network of 
private networks. Generally a media title is considered as a set of unequal or equal- 

30 sized cache units. When the access frequency to a particular media title is 
increasing, a proxy server coupled to a central server starts to progressively store 
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more of its cache units since its access behavior justifies its popularity. Similarly, 
when the access frequency to the media title decreases, the proxy server preferably 
removes its cache units if no space is otherwise available and makes room for 
cachiagoth^ frequently accessed video titles. Thearrangementbetweentheaccess 
S frequency to a video title and its corresponding caching size increases the caching 
perfomiance of the proxy server so as to reduce the bandwidth requirement on the 
data hnk between the proxy server and the central server. The data link typically 
operates on a network backbone and hence the overall operating cost for the media 
service provider can be substantially reduced. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates an exemplary configuration of a video delivery system 
including central and local video servers. 

FIG. 2 illustrates an exemplary video delivery system according to specific • 
1 S embodiments of the present invention. 

FIG. 3 A illustrates as an example three possible caching approaches where 
one quarter of the video data in the video stream is cached at Ihe proxy server in one 
embodiment. 

FIG. 3B is a schematic view of the caching of sub-blocks fix>m the ilh video 
20 title containing lOOblockswitheachblockdividedinto 10 sub-blocks to illustrate 
a preferred embodiment of the invention. 

FIG. 3C is a schematic view of an access profile in a time window W. 
FIG. 3D is a schematic view of an access profile in a time window W where 
the beginning time of the window is before the beginning of time or time = 0, 
25 FIG. 4 illustrates as an example a compounded caching effect where 

increasing portions of the video data in the video stream are cached at the proxy 
server in response to requests for the video title according to specific embodiments 
of the present invention. 

FIG. 5 illustrates an exenq)laiy configuration of a communication system 
30 in which the present invention may be practiced. 
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FIG. 6 illustrates an exemplary block diagram of a proxy server shown with 
a central server and a terminal device. 

FIG. 7 illustrates an exen5)laiy layout of a cache memory at the proxy 

server. 

5 FIG, 8 illustrates an exemplary block diagram of a central video server 

corresponding to the video server in FIG. 6. 

FIG. 9 illustrates an exemplary embodiment of a central video server 
according to an alt^nate embodiment of the present invention. 

FIG. 10 illustrates an exemplary process flowchart of the proxy module 
10 according to specific embodimrats of the present invention. 

FIG. 1 1 illustrates an exemplary process flowchart of the video server 
module according to specific embodiments of the present invention. 

FIG. 12 is a block diagram showing a representative example logic device 
in which aspects of the present invention may be embodied 
1 5 The invention and various specific aspects and embodiments will be better 

understood with reference to the drawings and detailed descriptions. In the different 
FIGs, similarly numbered items are intended to represent similar functions within 
the scope of the teachings provided herein. 

20 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Although the media delivery system described below is based on video 
streaming signals, those skilled in the art can s^reciate that the description can be 
equally appUed to audio streaming signals or other media or multimedia signals as 
well. The detailed description of the present invention here provides numerous 

25 specific details in ord^ to provide a tiiorough understanding of the present 
invention. However, it will become obvious to those skilled in the art that the 
present invention may be practiced without these specific details. In other 
instances, well known methods, procedures, components, and circuitry have not 
been described in detail to avoid unnecessarily obscuring aspects of the present 

30 invention. Before the specifics of the embodiments are described, a few more 
embodiments are outlined generally below. 
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The present invention involves inpart anew cache scheme referred to herein 
as Progressive video Cache (PVC). According to specific embodiments of the 
invention, a video (or other streannng data) title is handled as a set of equal sized 
(or varying size in other embodiments) cache miits. When the access fiequency to 
5 aparticular video title is increasing, the proxy server thenprogressively stores more 
of its cache units since its access behavior justifies its popularity. Similarly, when 
the video title's access firequency decreases, the proxy server can remove its cache 
units and make room for caching the hot video tities. The tight coiq>le between a 
video title's access frequency and its caching size inoreases the proxy server's 

10 caching performance and results in the reduction of backbone bandwidth 
requirement and overall operating cost. 

According to further specifics of the embodiments, once the caching policy 
is setup, the decision to add or reduce cache units is automatic, thus reducing 
management headaches. As noted above, the cache units fliat are stored are 

15 distributed in the video titie. An enhanced PVC scheme according to fiirther 
embodiments (referred to herein as Compounded-PVC) envisions that, when a 
proxy server is serving a request for a title, the scheme fiirther reduces the backbone 
bandwidth by caching extra cache units in response to subsequent multiple accesses 
to the same video titie. The proxy server is then able to retrieve the stored extra 

20 cache units for the subsequent accesses, thereby reducing the amount of data 
required from the central server and the backbone bandwidth required for sending 
data fi:om the central server. The later requests benefit fix)m the fact that, in 
addition to the cache units that are stored under the normal PVC scheme, extra 
cache units may now be obtained quickly and directly fix>m the proxy in the 

25 Compounded-PVC. 

Furthermore, it is well known in the art that logic or digital systems and/or 
methods can include a wide variety of different components and different fimctions 
in a modular fashion. The following will be apparent to those of skill in the art 
from the teachings provided herein. Different embodiments of the present invention 

30 can include different combinations of elements and/or functions. Different 
embodiments of the present invention can include actions or steps performed in a 
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different order than described in any specific example herein. Different 
embodinaents of the present invention can include groupings of parts or 
conQ>onents into larger parts or conq>onents different than described in any specific 
example herein. For purposes of clarity, the invention is described in terms of 

5 systems that include many different innovative contiponents and iimovative 
combinations of innovative components and known components. No inference 
should be taken to limit the invention to combinations containing all of ttie 
innovative components listed in any illustrative CTibodiment in this specification. 
The fimctional aspects of the invention, as will be understood fixjm the teachings 

1 0 herein, may be implemented or accomplishedusing any appropriate implementation 
environment or programming language, such as C-H-, Cobol, Pascal, Java, Java- 
script, etc. All publications, patents, and patent applications cited herein are hereby 
incorporated by reference in their entirety for all purposes. 

The invention therefore in specific aspects provides a streaining video/audi 

15 signals that can be played on various types of video-capable terminal devices 
operating under any types of operating systems regardless of what type of players 
are preinstalled in the terminal devices. 

Li specific embodiments, the present invention involves caching methods 
and sj^tems suitable for providing multimedia streanaing over a communication 
20 data network including a cable network, a local area network, a network of other 
private networks and the Litemet 

The present invention is presented largely in terms of procedures, steps, 
logic blocks, processing, and other symbolic representations that resemble data 
processing devices. TTiese process descriptions and representations are the means 
25 used by those experienced or skilled in the art to most effectively convey the 
substance of their work to others skilled in the art. The method along with the 
system to be described in detail below is a self-consistent sequence of processes or 
steps leading to a desired result These steps or processes are those requiring 
physical manipulations of physical quantities. Usually, though not necessarily, 
30 these quantities may take the form of electrical signals capable of being stored, 
transferred, combined, compared, displayed and otherwise manipulated in a 
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computer system or electronic computing devices. It proves convenient at times, 
principally for reasons of conunon usage, to refer to these signals as bits, values, 
elements, symbols, operations, messages, terms, numbers, or the like. It should be 
borne in mind that all of these sinoilar terms are to be associated with the 
5 appropriate physical quantities and are merely convenient labels applied to these 
quantities. Unless specijQcally stated olherwise as apparent from the following 
description, it is appreciated that throughout the present invention, discussions 
utilizing terms such as '^processing" or "computing" or * Verifying" or "displaying" 
or the like, refer to the actions and processes of a computing device that manipulates 

1 0 and transforms data represented as physical quantities within the device' s registers 
and memories into analog output signals via residmt transducers. 

FIG. 1 illustrates an exemplary configuration of a video delivery system 
including central and local video servers. The model is applicable to both the 
Internet (and Intemet2) and Intranet environment. In this model, a local service site 

IS installs one proxy video server and serves the video delivery service to its nearby 
end users. The local video servers are connected to a central video server via Wide 
Area Networks. The central video server is a video repository having all copies of 
video titles. A proxy video server caches firequently accessed video content locally 
and only gets the video title fix>m the central video server when it has no local copy 

20 available. The caching principle is the same for both Web access service and video 
delivery service. However, the video content imposes an even more challenge when 
considering its inherent nature of large storage requirement, high network 
bandwidth requirement, and time sensitive data delivery. The use of higiher video 
quality standards such as those by the Moving Picture Experts Group (MPEG-1, 

25 MPEG-2 formats) makes this challenge tougher. An improper caching decision 
causes wasting of precious resource such as backbone bandwidth and storage space. 
How to design a good video proxy scheme to address the above issues is addressed 
according to specific embodiments of the invention as d^cribed herein. 

30 nnmnmninatinTi S ystem Overview 
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FIG. 5 illustrates an exemplary computer communication configuration ia 
which the present invention may be practiced. Central server 102 together with a 
video/audio dataibase 104 fix>m a video/audio source comprising video/audio files 
that can be accessed on demand. As used herem, video/audio files or titles refer to 
5 any video footage, video films and/or video/audio clips that can be compressed or 
packed in any format One of the exemplary formats is MPEG. To play MPEG 
video files, one needs an MPEG viewer or client software executing in a personal 
computer with sujBBcient processor speed and internal memory. Another one of the 
popular formats for audio is MPEG-1 Audio Layer-3 (MP3), a standard technology 
10 and format for compressing a sound sequence into a very small file (about one- 
twelfih the size of the original file) while preserving the original level of sound 
quality when it is played tiarough a client program (player) downloadable &om 
many web sites. It should be noted, however, that the exact format of the video files 
do not affect the operations of the present invention. As will be noted and 
1 5 appreciated, the present invention ^pUes to any formats of the video or audio files 
as well as other multimedia data that may include, but not be limited to, binary data 
and files, hypertext files and scripts. 

Preferably data network 106 is a data network backbone, namely a larger 
transmission line. At the local level, a backbone is a line or set of lines that local 
20 area networks connect to for a wide area network connection or within a local area 
network to span distances efficiently (for example, between buildings). On the 
IntOTiet or other wide area network, a backbone is a set of paths that local or 
regional networks coimect to for long-distance interconnection. Coupled to data 
network A 106, there are two representative proxy servers 108 and 110 that each 
25 service representative terminal devices 116-119 via data network 112 and 114 
respectively. 

Datanetwork 112 and 114 are typically the Internet, alocal area network or 
phone/cable network through which terminal devices can recdve video files. The 
terminal devices may include, but not be limited to, multimedia computers (e.g. 1 16 
30 and 1 19), networked television sets or other video/audio players (e.g. 117 and 1 1 8). 
Typically the terminal devices are equipped with appUcations or capabilities to 



wo 01/020910 PCTAJSOO/25059 



13 

execute and display received video files. For example, one of the popular 
applications is an MPEG player provided in WINDOWS 98 from Microsoft. When 
an MPEG video file is streamed firom one of the proxy servers to the terminal 
device, by executing the MPEG player in a multimedia computer, the video file can 
5 be displayed on a display screen of the computer. 

To receive a desired video, one of the terminal devices sends in a request 
that may comprise the title of tiie desired video. Additionally the request may 
include a subscriber identification if the video services allow only authorized 
access. Upon receiving the request, the proxy server will first check in its cache if 

10 the selected video is provided therein, meanwhile the request is recorded by a 
request manager (see FIG. 6). The selected video will be provided as a streaming 
video to the tenninal device if the entire video is in the cache. Otherwise the proxy 
server proceeds to send a request to video central server 102 for the rest of the video 
if there are some xmits of the video in its cache memory, or for the entire video if 

1 S there is no units of the video in its cache memory. 

General Strateev for Viden rarbinp 

For purposes of discussion, in one embodiment, end-to-end video delivery 
can be imderstood with reference to the architecture described in FIG. 1. As an 

20 example, an end user uses its multimedia phonal computer ('TC*, or any other 
suitable tominal device) to issue a video playback request. The request is routed to 
the local proxy video server first. If the proxy server has the whole content of the 
requested video, it can serve the request immediately without forwarding the 
request to the remote central video server. This is called a cache kit and indicates 

25 no need of consuming the backbone resource. On the other hand, if the local proxy 
server does NOT have the video copy at all, it redirects the request to the remote 
video server and the video data will be streamed out fix>m the central server back 
to the local proxy server and then to the original requestor; this is called a cache 
miss. In this case, the video data flow over the backbone comection. A caching 

30 strategy goal is to improve the cache hit ratio (which includes a cache hit of a 
partially available video at local proxy server), which then reduces the cache miss 
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ratio and saves the backbone resource. However, storing the entire video copy at 
the proxy server requires local storage. Th«efore, if many video titles need to be 
stored, alargemassmemory must thenbe installed at thelocalproxy server andean 
be expensive. Thus, according to the invention, if portions of the popular video 
titles are stored at the proxy server, the cached portion may thenbe combined with 
themissingportionof the video title fcomthe central server and the combined video 
title is then streamed to the requester. Therefore, according to one aspect of the 
invention, for caching a video title, portions of the title that are distributed in the 
video title are cached. Since such portions are distributed in the video title, less 
video data would need to be retrieved from the central server and combmed with the 
cached portion for deUvery to the requester without interruption. Preferably, the 
portions of the video data that are stored are evenly distributed throughout the title, 
so that one can be sure that the peak bit rate required for delivering the missing 
portions from the central server would be reduced, as explained in more detail 
15 below. 

Caching efficiency is determined by two factors: minimization ofbackbone 
usage and of the amount of local storage at the proxy servers. Thus, if the video 
titles that are cached at the proxy servers are not those frequentty requested by 
users, this means that the local storage is taken up by less popular titles while the 
popular titles would need to be fetched from the central server, thereby reducing 
caching efficiency. Hence, one inqjoitantfector affecting caching efficioicy is the 
user access profile. Knowing the user access patterns can certainly help to design 
a better caching strategy. Hence, how to accurately predict user access bdiavior 
becomes an important issue in improving the local hit ratio. Previous studies have 
25 shown file user access proffle followed a Zipf-like distribution. This distribution, 
however, can only be used as a gaieral guideline and it may not appUcable to other 
cases. For instance, on the same day, different groups of audiences may watch 
different broadcasting programs at different timeperiods. It may have several types 
of access profile at one single day. In addition, the access profile usually represents 
30 thepastbehavioraiidassumingthenearfuturewiUfoUowthetrend.Thelongerthe 
profileupdateperiod, the less accuracy of the access profile. It may not be possftle 
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to forecast the access profile and be prepared the video titles cached on the local 
server in advance. 

Accordingly, the present invention in particular embodiments does not 
attempt to predict a access profile, but instead adjusts a caching policy whenev^ 

5 the access behavior changes. Thus, the invention makes sure at any moment of time, 
a caching policy can ride along witii the current access pattem and adjust caching 
parameters to improve the cache hit ratio. Because the access behavior can change 
at any time and by different magnitudes, the adjustment of a caching strategy 
according to a specific embodiment of the invention is completely automatic 

1 0 without any human intervention. This is a big advantage for system administrators. 

Proxv Video Server Cuchmg Models - 

In a Progressive Video Caching (PVC) strategy according to specific 
embodiments of the invention, a video title is handled as a set of equal sized (or, as 

15 discussed below, variable sized) cache units. When the access firequency to a 
particular video title is increasing, the proxy server then progressively stores more 
of its cache units because its access behavior justifies its popularity. Similarly, when 
the video title's access firequency decreases, the proxy server can remove its cache 
xmits and make room for caching the hot (most accessed) video tities. The tight 

20 coiq)le between a video title's access firequency and its caching size increases the 
proxy server's caching performance. It results ia the reduction of backbone 
bandwidth requirement and overall operating cost. Another advantage is that once 
the caching policy is setup, the decision to add or reduce can be made automatic, 
as fixrther described herein. 

25 Although, for ease of description, a PVC scheme is described herein with 

a video title partitioned into a set of equal sized cache units, this constraint can be 
relaxed. The PVC scheme can also partition a video title into a set of varied sized 
cache units, such as I, B and P frames in the MPEG formats, or in other 
embodiments described below. In such other scenarios, the PVC scheme is very 

30 suitable for video encoded as multilayered format and/or variable bit rate format, 
as e3q)lained below. 
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In a video deUvety model according to a further aspect of the invention, a 
local proxy server is the one pushing the video data to the user site. The data may 
be solely from the local proxy (for a cache hit of a wholly available video), solely 
from the remote server(foracache miss at the local proxy), or fromboth the local 
5 andremotesites(foracachehitofapartiallyavailablevideoatlocalproxyserver). 
FIG. 2 illustrates a video deUvery for the scenario of a cache hit of partially 
available video content rntheHG-.thelocalpioxy transmits flie video content to 
cUenf s multimedia PC. The local proxy server retrieves Ihe data segments 0, 8, 16 
locaUy and the other parts of data segments (e.g., data segment 1, 2, 3, 4, 5, 6, 7, 9, 
10 10, etc.) come from the remote cenlial server. This exaaq)le is for illustration 
p;^oses; the discussion below provides further details of additional embodiments 
and variations according to the invention. 

The example in FIG. 2 also reveals resource requirement ofthe proxy video 
server. The proxy server reads/writes the cache data from/into ttie disk drives (or 
15 other types of mass memory). Hence, the speed ofthe disk drives and its storage 
capacity affects the caching performance. The proxy server also needs main 
memory space to buffer the video data. Similarly, the network bandwidth at 
badcbone connection and user connection decide how much video data can flow 
toough it. The following sections discuss the impact of tiie aforementioned 
20 resource to the caching performance and feither aspects according to further 
specific embodiments of the invention. 

yiAea Retrieval Model 

Before defining Progressive Video Caching (PVC), the video retrieval 
25 model is considered. The video retrieval is viewed as aperiodic retrieval process, 
m each period of lengfli p. the system retrieves p Xr. of data amount for a client 
requesting a video title v, at data rate r, . This is to ensure that the data is ready 
before die time it is needed at the player. According to the present invention, a 
video title V, is treated as a series of video blocks: v". v/. ... v," -^ where n.- Xp 
30 denotes the video duration and each data block has tiie size of p Xr, For the 
purpose of understanding the present discussion, consider a two buffer scheme in 
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which one buffer stores data being deUvered to the user by the networking module 
and in the meantime the other buffer is used to store the next data block from eith^ 
the local disk drive or from the remote central server. The example of PVC 
definition according to the present iavmtion below is based on the above 
5 assimiption. 

General Description of Progressive Video Caching PVC 

Progressive Video Caching (PVC) according to the invention is a caching 
scheme for deciding the amount of video content and the portion of video data to 

10 be cached (or replaced). Each time a data caching or a replacement is required, the 
proxy server follows a PVC scheme according to the invention to identify the 
portion of a video data to fulfill the caching action or operation. 

The PVC defines a parameter called to specify caching or replacement 
units. Whenever the proxy server demands a caching (or a replacement of cached 

15 material) to a video title, 1/N (where N>V) portion of the video content is stored 
(or replaced) locally. In other words, with N equal 2, a proxy server stores or 
replaces half of a video title in each caching operation. In the special case of N 
equals 1, the caching unit is a whole video title. The value, in addition to being 
used to determine the caching size, defines the exact portion of cached (replaced) 

20 video data. The PVC scheme according to specific embodiments of the invention 
preferably directs that the 1/N portion of data be evenly located in the video title. 

While it is preferable for the 1/N portion of data be evenly located in the 
video title for practical reasons, this is not required. Thus, the sub-blocks cached 
can be distributed randomly over the title, such as where the sub-blocks are selected 

25 from the sequence of blocks by the use of a random number generator. In another 
embodiment described below, ttie same number of sub-blocks from each block of 
the title are cached by the proxy server. Or, one can store a sub-block about every 
n blocks along the time sequence of the blocks, n beiag a positive integer. In all 
such embodiments, one can insure reduction of the peak transmission bit rate of the 

30 central server. 
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Accordiagto furfher embodiments of the invention, "evenly located" canbe 
further understood by considering FIG. 3A which illustrates three possible 
explanations. The top part of FIG. 3A shows an original deHvety schedule for a 
video title which is delivered at data rate r. During each time period (i.e., p\ the 
5 proxy servermnstdeUverrJSr/? amount of data to maintain quahty of service. For 
a proxy server operating at the PVC with iV = 4, a cache operation to the video 
places portion of data into a local proxy. 

Approach A as illustrated in FIG. 3A inq)lements the data "even" 
requirement by marking data blocks in vertical direction . As indicated, Ihe proxy 
10 caches blocks 0, 4, and 8, i.e. it caches one of every four data blocks. At a next 
cache hit, the central server follows the origrnal schedule to deUver the remaining 
blocks over the backbone network. The central server deHvers nothing at tune 
periods during which the proxy server has the data locally stored. In this regard, the 
peak bandwidfli requirement of backbone connection has the same value as a cache 
1 5 miss. In other words, ^roach A does not reduce the peak bandwidth requiremeait 
of the central server, although it does reduce the average bandwidth requirement. 

Approach B as illustrated m FIG. 3A reduces the peak data rate by 
stretching the dehvery schedule specified m the approach A over the unused time 
slots. In oflier words, the central server divides the video data originally scheduled 
20 to be delivered over 3 regular time periods into 4 smaller blocks. One skilled in the 
art would understand how this may be acconq)lished so that it is not described 
herdn. The central server also alters its delivery schedule so that the 4 smaller 
blocks are thrai deUvered over 4 corre^onding time periods (3 regular time periods 
plus the one otherwise unused time period in ^roach A). It reduces the peak data 
25 rate by 25%, down ftom r to .75r. Because data is delivwed earlier dun its 
scheduled time, however, the proxy server needs additional buffer space ((5/2) x r 
x p instead of 2 x r x p in approach A) to cache the early arrived data and therefore 
the required of buffer space at the proxy is increased. 

Approach C as illustrated in HG. 3A marks the data block horizontally 
30 instead. At caching time, the proxy server keeps 1/4 portion of every datablock of 
a video title locally. This ^roach reduces the peak data rate of the backbone 
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comiection to .75r down from r. In the meantime, the buffer requirement remains 
at value of (2 x r x p), as required by the original (uncached) schedule. A PVC 
schCTie according to specific embodiments of the present invention adopts the 
approach C. 

5 

Oeneralired Proxv Video Server Models 

As iiErther illustration of specific embodiments of the invention, assume die 
total number of video blocks in video title is an integral multiple of N (i.e., 
> N and mod N=0). For each /th block of , which can be viewed as a set of N 

10 equal sized sub-blocks, denoted as , v^-' . For each video cache hit 

or replacement, the next available sub-block of tiie data blocks of the accessed video 
clip is targeted. For instance, assume the PVC scheme withiV^= 10, a video titlie 
with 100 blocks labeled in the time sequence in which they are to be sent as 
v/, vj^,...5 v,^^^. These 100 blocks are to be sent sequentially to the client or 

1 5 user, and thus may be arranged as such. Assuming that the local proxy server does 
not have video title in its cache memory. Preferably &e first request for video 
title V j will trigger die local proxy server to store data of (throughout where 
1 :^ j ^100) into its local disk drives. This is illustrated in FIG. 3B. FIG. 3B is a 
schematic view of video title Vj containing 100 blocks with each block divided into 

20 10 sub-blocks to illustrate the preferred embodiment of the invention. As shown 
in FIG. 3B, when the video title is requested, the local proxy s^i^er will discover 
that it does not have this title in its cache memory and would, therefore, start storing 
a portion of the title in its cache memory. According to approach C described 
above, it is preferable to store a portion of each of the 100 blocks. In reference to 

25 FIG. 3B, Ihe 1 00 sub-blocks y^) , with j ranging from 1 to 1 00, is then stored. This 
is shown in FIG. 3B schematically by the sub-blocks labelledil 1, il2,...,ilj...,ill0 
above the dotted Irae 132, where the sub-blocks are collectively referred to as unit 
132a, When the same title is requested again, the local proxy server may decide 
to increase the amount of title V; that is cached by storing another umt 134a of 100 

30 sub-blocks v/ widi/ ranging from 1 through 100 inits cache memory as indicated 
by the sub-blocks above the dotted line 134 in FIG. 3B. Yet anoflier cache hit to 
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the same video clip will add ^ into the local disk drive provided that data ^ 
and v/ are still in the local server. This may then continue until all of the title 
is cached. 

Thus if the local proxy server has enough resources and no cache 
replacement has happened, and the local proxy server decides to increase tibie sub- 
blocks of video title v, that are stored after each additional request for the title, then 
after 10 requests for video titie v,- , the local server will have the whole content of 
v^. The following equations defines the PVC caching effect described above in 
reference th FIG. 3B. With Civ^ indicating the current local cached content for 
video title v,-: 

C(v,)u |v^" \j = U,...,«,} 6 Civ,) foTl^m<k 

C(v,) = \{v%-= CM = 0 

Civ,) 



where k is the current or most recent hit count. 

The first sub-equation describes caching the dataiato the local proxy as long 
as the video title is not fiilly cached. The second sub-equation describes where there 

15 is no cache content at all for the accessed title. The third sub-equation describes the 
situation where the whole video title is cached in the local proxy aheady. 

Similarly, according to further embodiments of the invention, whenever the 
local proxy server makes a decision to do PVC replacement on a video titie, it 
removes the same amount of video data as the PVC caching does. The data portion 

20 or unit selected to be removed can be any one of the sets such as 132a, 134a, ...in 
FIG. 3B, each containing 100 sub-blocks that have been cached in the manner 
described above. Where the blocks are divided iato sub-blocks according to a 
multilayered scalable approach described below, it is advantageous to remove the 
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one set or unit that is most recently cached. The following equation illustrates this 
policy: 



where k is the current or most recent hit count. 

The above two equations describe that new cached content C(v,) for video 
title becomes the current v^minus the most recently cached portion. 

Predetenr tined Tachm g Cnntent 

According to further embodiments of the invention, after installation oflocal 
proxy server, a fiirther question is how to build up the local cache before the 
streaming service begins. Several possible approaches may be used according to the 
invention, such as no cachings average cachings or proportional caching based on 
access profile. 

No caching, the simplest approach, leaves the local cache content empty 
initially and build up the local content while doing streaming service. Tbis wastes 
the whole caching space at the beginning, which may be a major drawback, causing 
the requirement of higher backbone bandwidth at initial service period. 

The average caching (or average bandwidth) approach utilizes all local 
proxy space by storing equal portions of video data from each video title. It is a 
good choice provided that there is no access history or the target application shows 
no preference among the video tities. 

Proportional caching based on access profile caches databased on the video 
access history, with the expectation that past trends will continue. 

After the cache system begins operation, as will be understood by those 
dolled in the art, tiie local cache content will change from time to time to reflect the 
actual video access behavior. This can be done using any algorithm, such as by 
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increasing the number of sets of sub-blocks cached in proportion to the number of 
accesses within time periods, and removing them in proportion to the decrease in 
number of accesses when the number of accesses within time periods decrease. 
Unless there is a definite need to update the cache content (such as to manually 
5 cache a new video title release), the cache content using automatic updating is 
accurate enough. 

Resource Con fitrainte m Local Proxy 

As discussed above, a local proxy server according to further embodiments 
10 of the invention, uses PVC to selectively cache data locally* To fulfill the cache 
. operation, the local proxy server needs to supply sufficient resources, such as disk 
(or other mass memory) access bandwidth to write the selected data into local disks 
and to retrieve the cached data out fi:om the local disks, and disk (or other mass 
memory) storage space to store the selected data. 
1 5 Other local resources are the networking bandwidth (such as local interface 

to the backbone connection bandwidth between the remote central server and the 
local proxy server); and, the firont end network connection of the local proxy server 
and the end user sites. 

In practice, the local proxy server has limited resources with respect to 
20 memory buffer capacity, disk storage capacity and access bandwidth, and 
networking connection bandwidth These resource constraints have important 
impacts on the caching performance- The caching process and its resource 
requirements according to further embodiments of the invention are discussed 
below. 

25 According to further embodiments of the invention, the local proxy server 

begins the caching process after receiving a video playback request jfrom an end 
user as follows: 

Step 1 : Make sure there is sufficient finont end network bandwidth to deUver 

the new request. No matter whether the video data is ultimately 
30 delivered fi-om the remote central server, the local proxy server, or 

both, tiie local proxy needs to deliver it to the user site. This 
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demands suJQSlcient front-end networking bandwidth, otherwise, the 
local proxy will deny the request. 

Deliver the video data to the user site. Depending on the new 
request and current cache content, there are three possible cases: 
cache hit, cache miss, and partial cache hit. 
Cache hit The proxy server has complete content of the newly 
requested video title. The local proxy server itself can deliver the 
video data provided that there is available local disk bandwidth 
retrieving the data out of the local disk drives. 
Cache miss. The proxy server has nothiag from the newly requested 
video title. The video data must come from the remote central server 
solely. Hence, there must be enough available backbone to carry the 
data from the central server to the local proxy. Otherwise, the proxy 
server should reject the request. 
1 5 If there is enough backbone bandwidth, the proxy server can satisfy the new 

playback request. At this point, it is up to the proxy server to adjust its caching 
content to reflect the new request. The proxy server etx^loying PVC, in turn, 
considers the current disk resource including disk access bandwidth (to have access 
bandwidth to write the selected video data into the disk drives) and disk storage 
20 capacity (to have space to store the selected video data). If both resources are 
available, the proxy server stores a portion of the newly requested video content. If 
the local proxy has enough local disk bandwidth but insufficient local disk space 
toward the selected data portion, it invokes cache replacement operation (see 
discussion below) to make room for it. 
25 For the situation of not enough local disk bandwidth (whether there is 

available disk space), the caching will be called off. It means the proxy server will 
redirect the incoming data traffic (from the central server) to the end user without 
caching any data locally. 

Case C: Partial cache hit. The proxy server has partial copy of the newly 
30 requested video title stored in its local disk drives. This situation is 

very similar to the cache miss scenario except some of the requested 
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data wiU come from the proxy server. This impUes the request wUl 
consume less backbone bandMvidth resource (to deliver the data not 
in Ihe local proxy), the access bandwidth of the local disk drives (to 
retrieve the local cached data out and to write the newly cached data 
that is not already cached from the central server into the local 
disks), and ttie disk space to store the newly cached data. Wilhin the 
step, the request manager (see FIG. 6) inproxy server keeps track of 
accesses of and also refreshes the access profile for each requested 
video title. The caching replacement algorithm uses the iq)-to-date 
access profile as an important guidehne for replacing the old cached 
data with the new content. Further details of the caching 
replacement algorithm are discussed below. 

rarfiinp Replaconaat 

Caching r^lacemrait is replacing some existing video cache data with new 
content To do caching replacement, it is necessary to decide which video title and 
what portion of the data will be replaced. As mentioned above, one can smq)ly 
r^lace the most recently cached portion of a particular video. 

To resolve flie former concern (determining which video title to cache) is 
not as straightforward. The best case is to select tihe video title which has Ihe best 
chance ofbeing accessed in the fiiture. Because predicting the fiiture access pattern 
is difficult, the present invention in specific embodiments uses aheuristic approach 
to forecast the future access pattern. One approach is to use Ihe most current access 
profile as an indication of the predicted fiiture access profile. To do this, a proxy 
server according to Ihe invention needs to keq> track of each access request. As 
illustration, let A^t) indicate a sequence of accesses to video v, firam time 0 iq) to 
time t and is equal to .a? } where a/ indicates an access to video 

V, at time ty Therefore, tj for U}<m. In the case of tj = tj^j, it means two 
requests are happening at tiie same time. 

One way to measure the access profile is caUed equally-weighted access 

firequency and is defined as follows: 
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[a'^ |o < ^jfc < / and a/^ e 4 (^)} 



where / > FT 
where t <W 



where AFj(vpt) is the equally-weighted access firequency of video title V|at time t. 
The access firequency is the numher of requests to video title v,- during time period 
of ^ - JFand t. For the case of t < W, it measures access firequency in time period 
5 ofOandr^. The FTdenotes the value of time window. This is fiulher illustrated in 
reference to FIG. 3C, which is a schematic view of an access profile. As shown in 
FIG. 3C, time t is tiie point in time to determine an access profile of a particiilar 
video title in order to decide whether such title should he cached or replaced, and 
a time window W is set measuring back firom the time t. As shoAvn in FIG. 3C, this 

10 is indicated as the time window between t-W (the beginning time for the window) 
and t (the end time for the window). The niraiber of accesses for such video title 
is then added up, where accesses within the time window W are given equal weight. 
The simi of the number of accesses is then divided by the time window W to give 
the access firequency. FIG. 3C illustrates the case where the beginning time t-W of 

IS the window is afi;er the begiiming of time or time = 0 and corresponds to the iqpper 
equation for the access firequency above. FIG. 3D illustrates the situation where the 
time window W is such that t-W is before the beginning of time or time = 0 and 
corresponds to the second equation above for access firequency. 

Another sqpproach is to place different weights on accesses tiaat occurred at 

20 various time instants. In this approach, accesses that happened recentiy are give 
more weight than accesses that happened earli^. A PVC scheme according to 
fiirdier embodiments of the invention based on tiiis approach and the access 
firequency is called time-weighted access frequency and is defined as follows: 
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S ^ ^)) foJ^ t-W<ti,<t where r > FT 

X TiiC^i-^ ^ ^ik)) 0^ ^ifc ^ ^ where ^ < 



How to decide the length of time window Wis an interesting issue. A larger 
FT value means collecting access pattrai ovct longer period of time; thus accesses 
that happened earlier still carry some weight in choosing of the replacing video title. 
S On the other hand, a smaller IRT value. An access happened at time long before now 
may also plays a role in replacement decision. A large time window has the 
advantage of less replacements. However, if the access pattern changes in the short 
period of time, it is not quickly enough to reflect the trend and adapt to it. On the 
other hand, a replacement policy with small time window value can adjust its cache 
10 content much close to the current access pattern. However, it may trigger exicessive 
data replacement in a short period of time. 

PVC Enhancement: C-PVC 

The previous discussion was directed to embodiments of the invention 

15 directed to a single access to a video title. According to further embodiments of the 
invention, the invention is directed to multiple ongomg requests accessing different 
points of the same video title. This is particularly true for long video tities such as 
movies or for popular video titles. In this situation, according to flirther 
embodiments of the invention, the earlier ongoing request can be considered a 

20 prefetching of the later entered requests. Li this embodiment, the present invention 
is therefore able to fiather reduce thebackbonebandwidth requirement as discussed 
below. These further embodiments of the invCTlion may be referred to herein as 
Compounded Progressive Video Caching (C-PVC). 

FIG. 4 illustrates the coxiq)ounded caching effect with N (discussed above) 

25 set to 4. Assume each request will trigger the caching operation. The FIG. 4(A) is 
the PVC and FIG. 4(B) is the C-PVC scheme. As shown, there are three requests 
accessing the same video title. When request 3 enters, the requests 2 and 1 are 
accessing the data of time tj and t^o respectively. For the PVC scheme, the request 
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1 consumes backbone bandwidih of r. The request 2 needs backbone bandwidth of 
0.75r because the proxy server has cached 1/4 of data while serving the request 1 . 
Similarly, the request 3 demands bandwidth of 0.5r since the proxy has cached 2/4 
of data while serving the requests 2 and 3. 
5 FIG. 4B shows the C-PVC scheme. The proxy server serves the request 1 

by receiving the whole data firom the central server and caching 1/4 of the data fix>m 
it. When the request 2 enters, the request 1 is at time t^. The proxy server is still 
receiving from the central server for the request 1. By realizing there is a just 
entered request asking for the same video title, the proxy server can cache extra data 

10 in addition to its initially selected data. In our example, the request 2 only consumes 
0.5r bandwidth after time comparing to 0.75r in the PVC scheme. When the 
request 3 entered at time tj^, the request 2 only needs 0.25r backbone bandwidth 
after time tjg. The newly entered request 3 consumes only 0.25r backbone 
bandwidth after time ty. 

15 In this example, if the whole video iCTigth is tjo^. Thea the total backbone 

bandwidth traffic for PVC scheme is equal to 225r ( = lOOr + 0-75r + O.Sr for 
request 1 , 2, and 3 respectively.) For C-PVC scheme, the total backbone bandwidth 
usage is equal to ISSr. 

Among three requests, they account for lOOr, (3 x0.75xr + 7x0.5xr + 

20 90x0.25xr), and (7x0,5xr + 93x0.25xr), for request 1, 2, and 3 respectively. In 
compared to PVC scheme, tiie C-PVC scheme in this example saves backbone 
bandwidth of 31.11%. 

Scalable Multilavered Approach 

25 According to International Standard ISO/IEC 13818-2, first edition. May 

15, 1996, which is incorporated herein by reference, several types of scalable video 
coding are proposed. This standard proposes three types of scalability: SNR 
scalability, spatial scalability and temporal scalability. In each of the three types of 
scalabilities, it is envisioned that a base layer would provide basic video data 

30 adequate for reproducing a video image. Thus, for viewers with limited bandwidth, 
all that is transmitted is the basic layer. For viewers with higher bandwidth 
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capability, each of the three types of scalabilities has in addition one or more 
enhancement layers, which, when combined with the basic layer information, 
enhance the video qnahty seen by the viewer. Thus in SNR scalabiUty, all layers 
have the same spatial resolution. The base layer provides the basic video quality. 
5 The enhancement lay^ increases the video quality by providingrejSnementdatafor 
the DCT coefficients of the base layer. In spatial scalability, the base layer provides 
the basic spatial resolution and temporal rate. The enhancement layer uses the 
spatially interpolated base layer to increase the spatial resolution. In temporal 
scalability, a base layer provides the basic temporal rate. The enhancement layer 

10 uses temporal prediction relative to the base layer. The base and enhancement 
layers can be combined to produce a Ml temporal rate output. MPEG 2 supports 
the above-described scalability approach. Reference to the MPEG 2 approach to 
scalabiUty is made to Chapter 11 entitled "MPEG 2" of Video Demystified, A 
Handbookfor the Digital Engineer, Second Edition, HighText Interactive, Inc., San 

15 Diego, California, 1996, pp. 503-512. Such Chapter is incorporated here in its 
entirety by reference. 

In addition to the above-described scalability approach, other types of 
scalable embodiments are possible. 

In reference to spatial scalable coding, Jfor example, in consumer electronics 

20 most video sources use an interlaced display format: each firame is scanned out as 
two (odd and even) fields that are separated temporally and ofTset spatially in the 
vertical direction. Thus, in one form of spatial scalable coding, the lower layer may 
comprise one of the two fields of an interlaced disfplay format and the enhancement 
layer may comprise the other field. Thus, when there is inadequate bandwidth for 

25 transmittmg both fields fiom the proxy server to the client or clients, only the basic 
layer comprising one of the fields is sent, where the only one field sent will provide 
a somewhat degraded but adequate video image. If the bandwidtii fmm the proxy 
server to the client is adequate, however, the enhancement layer comprising the 
other field is sent as well so that the two fields together will provide a better quality 

30 video image to the cUent. In other words, the basic layer in the spatial scalable 
coding approach would comprise the video data along one set of scan lines (e.g. odd 
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numbered scan lines) according to any one of fhe commonly used standards such 
as NTSC, and the enhancement layer would comprise video data along the other set 
of scan lines (e.g. even nimibered scan lines) comprising the other field according 
to the same standard. When the link between the proxy server and the client has 
S limited bandwidth so that only the basic layer can be transmitted, the information 
in the only one field of the basic layer can be converted into a fiill video fiame by 
any one of many well known algorithms such as scan line interpolation and field 
merging as described, for example, in Chapter 9 entitled "Video Processing" of 
Video Mystified, A Handbook for the Digital Engineer^ Second Edition, HighText 

10 Interactive, Inc., San Diego, California, 1996, pp. 386-394; such Chapter is 
incorporated here in its entirety by reference. While the example above envisions 
dividing the video information into two equal parts for partitioning into the tWo 
layers, it is possible to partition them into unequal parts, such as one quarter for the 
basic layer and three-quarters for the enhancement layer, and possible to further 

1 5 divide the three-quarts into more than one enhancem^t layers, where the number 
of enhancement layers sent can be determined as a fimction of available bandwidth. 

Another example of a temporal scalable approach may be as follow. Where 
a video source provides video data at a particular sampling rate. Some of the video 
data samples fi:t>m the source are grouped together to comprise the basic layer 

20 transmitted at a sampling rate that is lower than that of the source, and the 
remaining samples grouped together also and transmitted at a lower sampling rate 
will comprise the enhancement layer. As in the situation of the spatial scalable 
approach described above, where the bandwidth does not permit transmission of 
both the basic layer and the enhancement layer, only the basic layer will be 

25 transmitted and known techniques may be employed to convert the video data at the 
lower sampling rate to a full video fi-ame. Where the bandwidth permits 
transmission of both the basic and enhancement layers, the samples fi-om both 
layers will be combined in a known manner to presrat a better quality video. 
Again, the division of the samples from the source into Hie two layers can be done 

30 so that the two lays do not have the same number of samples, and it is further 
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possible to divide the samples into a basic layer and more than one enhancement 
layer. 

The above-described schemes may be used for implementing ttie preach 
C in FIG. 3A. Thus, in the case of the spatial scalable ^proach described above, 

5 the video data along 1/4 of the scan lines of the video frame may be cached where 
such scan lines are preferably evenly spaced across the frame, so that only the video 
data along the Training 3/4 of the scan lines of the video frame would need to be 
fetched from the central server. Similarly, in a temporal scalable approach, 1/4 of 
the video samples also preferably evenly spaced temporally across the video frame 

1 0 may be cached while the remaining samples may be fetched from the central server 
to implement approach C in FIG. 3 A. 

Structural Ex am ples of Proxy Server and Ca che memory 

To better understand the invention, FIG. 6 shows ablock diagram of aproxy 
15 server corresponding to proxy server 108 or 1 10 inFIG. 5 to illustrate an exemplary 
configuration of a communication system in which the present invention may be 
practiced. 

According to one embodiment of the present invention, the proxy server is 
loaded with a compiled and linked version of an embodiment of the present 
20 invention, when executed by the process, the compiled and link version may 
perform the following method: 

detennining the number of requests to a video title; 
storing in a cache of a proxy server, in response to the number of flie 
requests for the video title, a corresponding plurality of cache units of the video 
25 title; 

updating the cache every time a new request is received; wherem the 
updating comprises: 

storing in the cache more cache units of the video title if the new request 

corresponds to the video title; and 
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deleting from the cache at least one or more cache units of the video title if 
the new request does not correspond to the video title, or not deleting any cache 
units if there is enougfh storage space for caching new cache imits or other reasons. 
FIG- 7 shows an exemplary layout of a cache memory at the proxy server. 
5 It is assumed each video is equally divided into N cache units. As described above, 
each cache unit may comprise different sub-blocks fix»m different blocks, such as 
unit 132a, 134a. Depending on tiie access frequency, the nuniber of the cache units 
of each video varies. In other words, the higher the number of the requests to a 
video title, the more the number of liie cache units of the video are cached in the 

10 cache memory in the proxy server. When there are no more requests to the video 
title, die cache memory are updated, namely the number of the ciache units of the 
video is reduced or totally deleted, leaving room for other video titles. The 
progressive video caching technique result in a scalable caching mechanism and 
inq^rove significantiy the overall performance of the medial delivery system. 

15 FIG. 8 shows the block diagram of the central video server corresponding 

to server 102 of FIG. 1 . The load manager receives requests £rom a proxy server 
and ensures a requested video is delivered in a most efi&cient way. The content 
manager provides typically a background to the tenidnal device to display the 
video. The backgroundmay include additional information that the service provider 

20 prefers the user of the terminal device to attend, such as service/product promotion 
information. 

FIG. 9 shows an embodiment of the central video server according to the 
present invention. 

To ftirther understand the present invention, FIG. 10 and FIG. 11 show, 
25 respectively and according to one embodiment of the present invention, a process 
flowchart of the proxy module and the video server module each executed in the 
proxy server and the central video server. 

The media delivery system as described herein in accordance with one 
aspect of the present invention is robust, operationally efficient and cost-effective. 
30 The progressive caching mechanism provides the best use of the cache memory in 
proxy servers and permits seamless delivery of streaming video with guaranteed 
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quality of services. In addition, the present invention may be used in connection 
with presentations of any type, including sales presentations and product/service 
promotion, whichprovides the video service providers additionalrevenueresources. 
The processes, sequences or steps and features discussed herein are related 

5 to. each other and each are believed independently novel in the art. The disclosed 
processes and sequences may be p^ormed alone or in any combination to provide 
a novel and nonobvious file structure system suitable for media delivery system. It 
should be understood tihat the processes and sequences in combination yield an 
equally independently novel combination as well, even if combined in their 

10 broadest sense. 

Other Embo diments 

The invention has now been described with reference to specific 
embodiments. Other embodiments will be apparent to those of skill in the art. In 

15 particular, a user digital information appliance has generally been illustrated as a 
personal computer. However, the digital computing device is meant to be any 
device for interacting with a remote data application, and could include such 
devices as a digitally enabled television, cell phone, personal digital assistant, etc. 
FurthCTnore, while the invention has in some instances been described in 

20 trans of cUent/server application environments, tihis is not intended to limit the 
invention to only those logic enviromnents desaibed as client/server. As used 
herein, "client" is intended to be understood broadly to comprise any logic used to 
access data firom aremote system and "server** is intended to be understood broadly 
to comprise any logic used to provide data to a remote system. 

25 It is understood that the examples and embodiments described herein are for 

illustrative purposes only and that various modifications or changes in light thereof 
will be suggested by the teachings herein to persons skilled in the art and are to be 
included within the spirit and purview of this plication and scope of the claims 
and their equivalents. 

30 

Frnhndimen t in a Progr aTnined Tnfnrmation Appliance 
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As shown in FIG. 12, the invention can be implemented in hardware and/or 
software. In some embodiments of the invention, different aspects of the invention 
can be implemented in eitiier cUent-side logic or a server-side logic. As will be 
miderstood in the art, the invention or components thereof may be embodied in a 
5 jBxed media program component containing logic instructions and/or data lhat when 
loaded into an appropriately configured computing device cause that device to 
perform according to tiie invention. As will be understood in the art, a fixed media 
program may be dehvered to a user on a fixed media for loading in a users 
computer or a fixed media program can reside on a remote server that a user 
10- accesses through a communication medium in order to download a program 
component. 

FIG. 12 shows an information appliance (or digital device) 700 that may be 
understood as a logical apparatus that can read instmctions fi-om media 717 and/or 
network port 719. Apparatus 700 can th^eafter use those instructions to direct 

1 S server or client logic, as understood in the art, to embody aspects of the invention. 
One type of logical apparatus that may embody the invention is a computer system 
as illustrated in 700, containing CPU 707, optional input devices 709 and 711, diisk 
drives 715 and optional monitor 705. Fixed media 717 may be used to pirogram 
such a system and may represent a disk-type optical or magnetic media, magnetic 

20 tape, solid state memory, etc.. The invention may be embodied in whole or in part 
as sofiware recorded on this fixed media. Communication port 719 may also be 
used to initially receive instructions that are used to program such a system and may 
represent any type of communication connection. 

The invention also may be embodied in whole or in part within the circuitry 

25 of an application specific integrated circuit (ASIC) or a programmable logic device 
(PLD). In such a case, the invention may be embodied in a computer 
understandable descriptor language which may be used to create an ASIC or PLD 
that operates as herein described. 
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WHAT IS CLAIMED IS : 

1 . Axnefhod of caching in a system for transmitting apluralily of media 
data titles to one or more client(s) j&om a central server and a proxy server, wherein 

5 each title is divided into blocks to be transmitted to tiie one or more client(s) in a 

time sequence, and each block is divided into sub-blocks, conoprising: 

identifying which sub-blocks from different blocks of each title that are to 

be cached, wherein the identified sub-blocks include ones that are distributed over 

the blocks of at least one title; and 
10 caching the identified sub-blocks under the control of the proxy server to 

reduce the transmission bit rate of the central server for transmitting the titles. 

2. The method of claim 1, wherein the cached sub-blocks are cached 
for time periods that are independent of passage of time. 

15 

3. The method of claim 1 , wherein the caching caches substantially the 
same number of sub-blocks from each block of said at least one titie. 

4. The method of claim 1 , wherein the media titles include video titles, 
20 and the sub-blocks include video frames, and each block is divided into video 

frames that are to be transmitted sequentially, and fiirther comprising inserting the 
cached video firames into a stream of video frames from the central server to form 
a combined stream and sending the combined stream to the cUent(s). 

25 5. The method of claim 1, wherein the media titles include video tities, 

and the sub-blocks conaprise partial information of video frames, wherein tiie video 
frames are to be transmitted sequentially, fiirfher comprising combining the partial 
information of video frames from the proxy server with complementary partial 
information of such video frames from the central server into complete video 

30 frames and sending the complete video frames to the cUent(s). 
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6. The method of claim 5, wherein the partial information comprise 
video information along some scan lines of video frames, further comprising 
combining the video information along such scan lines with complementary video 
information along other scan lines of such video frames from the central server into 

5 complete video frames and sending the complete video frames to the client(s). 

7. The method of claim S, wherein the partial information comprise 
video information obtained at a set of sampling times and at a first sampling rate 
lower than that of a video source from which said information originates, further 

10 comprising combining the video information at the lower first sampling rate from 
the proxy server with complementary video information taken at sampling times 
different from the set of sampling times of such video frames from the central 
server into video data at a sampling rate higher than the first sampling rate and 
sending the video data at the higher sampling rate to the client(s). 

15 

8. The method of claim 5, wherein the partial information comprise 
video information in a basic layer and the conq>lementary partial information 
comprises video information in an enhancement layer, said basic and enhancement 
layers being defined according to spatial, signal-to-noise or temporal scalability. 

20 

9. Themethodof claim 1, wherein theidentifyingismadeasafrmction 
of an access profile of the tities at the proxy. 

10. The method of claim 1 , wherein prior to any accesses of the titles by 
25 the client(s), an average caching ^proach utilizes storage at the proxy server by 

storing a substantially equal number of sub-blocks from each title. 

1 1 . The method of claim 1 , wherein prior to any accesses of the tities by 
the client(s), a proportional caching approach utilizes access history data to 

30 determine how much of each title to cache. 
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12. The method of claim 1, wherein after the system starts operation, 
cache content at the proxy server will change from time to time to reflect actual 
access hehavior. 

5 13. The method of claim 1, fiirfher comprising beginning a cachiiig 

process at the proxy server after receiving a title request from a client by ensuring 
there is sufficient bandwidth from said proxy to such client to deliver the request 
and if not, denying the request 

10 14. The method of claim 13, fiirther comprising delivering the complete 

content of the requested title when such content is in local storage of said proxy 
server. 

15. The method of claim 13, fijrfher comprising: 

15 when said proxy server does not have complete content of the requested 

title, determining if there is sufficient available backbone bandwidth to carry said 
title from the central server to said proxy server and if not, rejecting the request 

16. Themethod of claim 15, finrther comprising activating aprogressive 
20 caching process to adjust cache content at said proxy server to reflect the requested 

titie. 

17. The method of claim U fiirther comprisiag replacing a cached 
portion of a particular title by deleting the most recently cached portion of such 

25 title. 

18. The method of claim 1, further comprising deciding which titles 
shall be subject to caching replacemmt using a most current access profile as an 
indication of a future profile. 

30 
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19- The method of claim 1, further comprising keeping track of each 
access request at the proxy server in order to determine which titles shall be subject 
to caching replacement. 

5 20. The method of claim 1, furliher comprising deciding which titles 

shall be subject to caching replacement using a current access profile as an 
indication of &e future profile, wherein said deciding includes: 

defining a time window ending at the time of the caching replacement; 
calculating an access frequency of each title in a storage of the proxy server, 
10 said access firequency being a function of the accesses to such title during the time 
window or a portion thereof; and 

performing the caching replac^nent in response to the access frequencies 
of the titles in the storage. 

15 21. The method of claim 20, wherein said access firequency is 

proportional to the sum of the accesses to such title during the time window or a 
portion thereof. 

22. The method of claim 20, wherein said access firequency is 
20 proportional to a time-weighted sum of the accesses to such title during the time 

window or aportion thereoj^ with the time weighting in favor of accesses occurring 
more recendy in the window. 

23. The method of claim 1, further comprising detecting multiple 
25 ongoing requests fi*om clients for a title received at dififerent times during caching 

in response to an initial request of said titie, and increasing the number of sub- 
blocks cached fi-om the blocks of at least one title in response to a subsequent 
request of said titie. 

30 24- A method of deciding an amount of a data titie for a caching action 

comprising: 
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defining a parameter iV to specify caching units; and 

each time a caching action is activated, perfonning said action on one or 

more l/A^portions of said data title (where JV> 1), wherein said LWportion of said 

data title is distributed in said data title. 

5 

25. The method of claim 24, wherein said portion of said data title 
is evenly distributed by: 

dividing said data title into a number of blocks; 
dividing each block into a number of sub-blocks; and 
10 for each caching action, selecting the same number of sub-block(s) from 

each block of at least one title. 

26. The method of claim 24, wherein said caching action comprises 
addiag data to a cached portion of said title. 

15 

27. The method of claim 24, wherein said caching action comprises 
removiug data from a cached portion of said title. 

28. A system for delivering media information; the system comprising: 
20 aplurality of proxy servers, each servicing anumber of terminal devices and 

receiving a request fix>m one of said tenninal devices when a user of said one of said 
tenninal devices desires for a media title; each of said proxy servers comprising a 
cache memory for storing units of some of titles; wherein the number of units of 
each of said titles is detennined by a request frequency to said each of said titles; 
25 and 

a central media server coupled to said proxy servers; said central media 
server having a storage space for storing a plurality of said titles and providing data 
from one of said titles when receiving a proxy request from one of said proxy 
serves. 

30 

29. A system for delivering media information; flie system comprising: 
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aplurality of pioxy servers, each servicing a niimber of tenniiial devices and 
receiving a request fix>m one of said terminal devices when a user of said one of said 
tenninal devices desires a media title fiom a plurality of media titles; wherein at 
least one of said proxy servers comprises acache memory storing anumber of units 
5 of at least one of said titles; wherein the units of the at least one title stored are 
distributed over such title; and 

a central server coupled to said proxy servers; said central server having a 
storage space for storing a plurality of said titles and providing data from one of 
said titles when receiving a proxy request from one of said proxy servers. 

10 

30. The system of claim 29, wherein said at least one proxy server stores 
the units of the at least one title for time periods that are independent of passage of 
time. 

IS 31. The system of claim 29, wherein the at least one title is divided into 

blocks to be transmitted to the one or more user(s) in a time sequence, and each 
block is divided into sub-blocks, wherein the at least one proxy server caches the 
same number of sub-blocks from each block of said at least one title. 

20 32. The method of claim 29, wherein the at least one title includes a 

video divided into blocks to be transmitted in a time sequence, and each block is 
divided into sub-blocks, and the sub-blocks comprise partial information of video 
frames, wherein the video frames are to be transmitted sequentially. 

25 33. The system of claim 32, wherein the at least one proxy server 

combines the partial information of video frames with complementary partial 
information of such video frames from the central server into complete video 
frames and sends the complete video frames to user(s) 

30 34. The system of claim 33, wherein the partial information comprise 

video information along some scan lines of video frames, and wherein the at least 
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one proxy server combines the video information along such scan lines with 
complementary video information along other scan lines of such video frames from 
the central server into complete video frames and soids the conq[>lete video frames 
to the user(s). 

5 

35. The system of claim 33 wherem the partial information comprise 
video information obtained at a set of sampling times and at a first sampling rate 
lower dian that of a video source from which said information originates, and 
wherein the at least one proxy server combines the video information at the lower 
1 0 first sampling rate with complementary video information taken at sampling times 
different from the set of sampling times of such video firames from the central 
server into video data at a sampling rate higher than the first sampling rate and 
sends the video data at the higher sampling rate to the user(s). 

15 36. The system of claim 32, wherein the sub-blocks comprise 

information in a base layer of a scalable multilayer system. 

37. The system of claim 29, where the number of units is a fimction of 
an access profile of the at least one title at the at least one proxy servo:. 

20 

38. A method of caching in a system for transmitting a pluraKty of data 
titles to one or more client(s) fix>m a central server and aproxy server, wherein each 
title is divided into blocks to be transmitted to the one or more client(s) in a time 
sequence, and each block is divided into sub-blocks, comprising: 

25 identifying which sub-blocks fix)m different blocks of each tide that are to 

be cached, wherein the identified sub-blocks include ones that are distributed over 
the blocks of at least one title; and 

caching the identified sub-blocks under the control of the proxy server to 
reduce the transmission bit rate of the central server for transmittkig the titles. 
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39. The method of claim 38, wherein the cached sub-blocks are stored 
for time periods that are independent of passage of time. 

40. The method of claim 38, wherein the caching caches the same 
5 nmnber of sub-blocks from each block of said at least one title. 

41. A computer readable storage device embodying a program of 
instmctions executable by a computer to perform a method of caching in a system 
for transmitting a plurality of media data titles to one or more client(s) from a 
central server and a proxy server, wherein each title is divided into blocks to be 
transmitted to the one or more client(s) in a time sequence, and each block' is 
divided into sub-blocks, said method comprising: j 

identifying which sub-blocks from different blocks of each title that are to 
be cached, wherein the identified sub-blocks include ones that are distributed over 
the blocks of at least one title; and 

caching the identified sub-blocks under the control of the proxy server to 
reduce the transmission bit rate of the central server for transmitting the titles. 

42. The device of claim 41, wherdn the cached sub-blocks are stored for 
time periods that are independent of passage of time. 

43. Thedeviceof claim 41, wherein the caching caches substantially the 
same number of sub-blocks from each block of said at least one title. 

25 44- The device of claim 4 1 , whereiu the media titles include video titles, 

and the sub-blocks include video frames, and each block is divided into video 
frames that are to be transmitted sequentially, said method finiher comprising 
inserting the cached video frames into a stream of video frames from the central 
server to form a combined stream and sending the combined stream to the client(s). 
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45. Thedeviceofclaim41,wherein1hemediatitlesiiicludevideotitles, 
and the sub-blocks comprise partial information of video frames, wherein the video 
frames are to be transmitted sequaitially, said method ftrtiier comprising 
combining the partial information of video frames from the proxy server with 

5 complementaiypartialinformation of sudi video framesfromthecentralserverinto 

complete video frames and sending the complete video frames to the client(s). 

46. The device of claim 45, wherran the partial information comprise 
video information along some scan lines of video frames, said meHiod further 

10 comprising combining flie video information along such scan lines with 
complementary video information along other scan lines of such video frames from 
the central server into complete video frames and sending the complete video 
frames to the client(s). 

15 47. The device of claim 45, wherein the partial information comprise 

video information obtained at a set of sampling times and at a first sampling rate 
lower than that of a video source from which said information originates, said 
method fiirther compriang combining the video information at the lower first 
gampliTig rate from flie proxy server wifli conq)lementaty video information taken 

20 at sampling times different from flie set of sampling times of such video fiames 
from the central server into video data at a sanq)ling rate higher than the first 
sampling rate and sending the video data at the higgler saii^)ling rate to the client(s). 

48. The device of claim 45, wherein the partial information comprise 
25 video information in a basic layer and the complementary partial information 

comprises video information in an enhancement layer, said basic and enhancement 
layers being defined according to spatial, signal-to-noise or tenq)oral scalability. 

49. The device of claim 4 1 , wherein the identifying is made as a function 
30 of an access profile of the titles at the proxy. 



wo 01/020910 



PCT/USOO/25059 



43 

50. The device of claim 41 , wherein prior to any accesses of the titles by 
the client(s), an average caching 2q>proach utilizes storage at the proxy server by 
storing a substantially equal number of sub-blocks from each title. 

5 51. The device ofclaim 41, whereinprior to any accesses ofthe titles by 

the client(s), a proportional caching ^roach utilizes access history data to 
detemiine how much of each title to cache. 

52. The device of claim 41, wherein after the system starts operation, 
10 cache content at the proxy server will change from time to time to reflect actual 

access behavior. 

V 

53 . The device of claim 41 , said method further comprising beginning 
a caching process at the proxy server after receiving a title request from a client by 

1 5 ensuring there is sufficient bandwidth from said proxy to such client to deliver the 
request and if not, denying the request. 

54. The device ofclaim 53, said method frirther comprising delivering 
the comqplete content of the requested title when such content is in local storage of 

20 said proxy server. 

55. The device ofclaim 53, said method frirther comprising: 

when said proxy server does not have complete content ofthe requested 
titie, determining if there is sufficioit available backbone bandwidth to carry said 
25 titie from the cootral server to said proxy server and if not, rejecting the request 

56. The device ofclaim 55, said method further comprising activating 
a progressive caching process to adjust cache content at said proxy server to reflect 
the requested titie. 

30 
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57. The device of claim 41, said method further comprising replacing a 
cached portion of a particular title by deleting the most recently cached portion of 
such title. 

S 58. The device of claim 41, said method further comprising deciding 

which titles shall be subject to cachiag replacement using a most current access 
profile as an indication of a future profile. 

59. The device of claim 41, said method further comprising keeping 
10 track of each access request at the proxy server in order to determine which titles 

shall be subject to caching replacement. 

60. The device of claim 41, said method further comprising deciding 
which titles shall be subject to caching replacement using a current access profile 

15 as an indication of the future profile, wherein said deciding includes: 

defining a time window ending at the time of the caching replacement; 
calculating an access firequency of each title in a storage of the proxy server, 
said access fi^uency being a function of the accesses to such title during the time 
window or a portion thereof; and 
20 perfomung the caching replacement in response to the access firequencies 

of the tities in the storage. 

61. The device of claim 60, wherein said access firequency is 
proportional to the sum of the accesses to such titie during the time window or a 

25 portion thereof. 

62. The device of claim 60, wherein said access firequency is 
proportional to a time-weighted sum of the accesses to such title during the time 
wiiidow or a portion tiiereofi with the time weigihting in favor of accesses occurring 

30 more recentiy in the window. 
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63. The device of claim 41, said method further comprising detecting 
multiple ongoing requests from clients for a title received at different times during 
caching in response to an initial request of said title, and increasing the number of 
sub-blocks cached fix>m Ihe blocks of at least one title in response to a subsequent 

S request of said title. 

64. A computer readable storage device embodying a program of 
instructions executable by a computer to perform a method of deciding an amount 
of a data title for a caching action, said method comprising: 

10 defining a parameter N to specify caching imits; and 

each time a cachiag action is activated, performing said action on one or 
more 1/N portions of said data title (where N> 1), wherein said l/3Vportion of said 
data title is distributed in said data titie. 

IS 65. The device of claim 64, wherein said ly7\r portion of said data title 

is evenly distributed by: 

dividing said data title into a number of blocks; 

dividing each block into a number of sub-blocks; and 

for each caching action, selecting the same number of sub-block(s) firom 

20 each block of at least one title. 

66. The device of claim 64, wherein said caching action comprises 
adding data to a cached portion of said title. 

25 67. The device of claim 64, wherein said caching action comprises 

removing data from a cached portion of said title. 

68. A method for transmitting a program of instructions executable by 
a computer tx> perform aprocess of caching in a system for transmitting aplurality 
30 of media data titles to one or more client(s) from a central server and aproxy server, 
wherein each titie is divided into blocks to be transmitted to the one or more 
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cliCTt(s) in a time sequence, and each block is divided into sub-blocks, said method 
comprising: 

transmitting to a client device a program of instructions; and 
enabling the client device to perform, by means of such program, the 
5 following process: 

identifying which sub-blocks fiom difTi^rent blocks of each title that are to 
be cached, wherein the identified sub-blocks include ones that are distributed over 
the blocks of at least one title; and 

caching the identified sub-blocks under the control of the proxy server to 
10 reduce the transmission bit rate of the central server for transmitting the titles. 

69. The method of claim 68, wherein the program enables the cached 
sub-blocks to be stored for time periods that are independent of passage of time. 

1 5 70. The method of claim 68, wherein the program enables the caching 

to cache substantially the same number of sub-blocks firom each block of said at 
least one title. 

71. Tliedeviceofclaim68,whereinthemediatitlesincludevideotitles, 
20 and the sub-blocks comprise partial information of video firames, wherdn the video 

firames are to be transmitted sequentially, wherein the program enables the client 
device to further perform, by means of such program, the following: combining the 
partial information of video firames fix>m the proxy server with complementary 
partial information of such video frames firom the central server into complete video 
25 firames and sending the complete video firames to the cUent(s). 

72. The method of claim 71, wherein the partial information comprise 
video information in a basic layer and the complementary partial information 
comprises video information in an enhancment layer, said basic and enhancement 

30 layers being defined according to spatial, signal-to-noise or temporal scalability. 
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73. The method of claim 68, wherein the identifying is made as a 
function of an access profile of the titles at the proxy. 

74. A method for transmitting a program of instructions executable by 
5 a computer to perform a process of deciding an amount of a data title for a caching 

action, said method comprising: 

transmitting to a client device a program of instructions; and 

enabling the client device to perform, by means of such progranot, the 

following process: 
1 0 defining a parameter N to specify caching units; and 

each time a caching action is activated, performing said action on one or 

more 1/iV portions of said data title (where iV^> 1), wherein said l/?Vportion of said 

data title is distributed in said data title. 

15 75. The method of claim 74, wherein said l>5Vportion of said data title 

is evenly distributed by: 

dividing said data title into a number of blocks; 

dividing each block into a number of sub-blocks; and 

for each caching action, selecting the same number of sub-block(s) fi'om 

20 each block of at least one title. 

76. The device of claim 74, wh^ein said caching action comprises 
adding data to a cached portion of said title. 

25 77. The device of claim 74, wherein said caching action comprises 

removing data firom a cached portion of said title. 
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